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ABSTRACT 


The  Network  Centric  Warfare  Simulation 
(NETWARS)  program  was  initiated  in  1996 
W  LT  General  Buchholz,  the  director  for 
Command,  Control,  Communications,  and 
Computer  System,  J-6  (Joint  Staff).  This 
was  in  response  to  concerns  that  C41SR 
networks  and  systems,  when  exposed  to  full 
operational  loading  and  unanticipated 
effects,  may  be  susceptible  to  performance 
degradation  and  failure.  The  objective  of 
the  NETWARS  program  is  to  provide  a 
simulation  environment  that  allows  the  end 
user  to  conduct  communications  burden 
analyses,  perform  communication 
contingency  planning  and  assess  the 
performance  of  emerging  communications 
technology.  A  key  component  to  the  success 
of  NETWARS  is  service  involvement.  The 
services  are  providing  the  entities,  traffic 
loading,  networks/links,  movement 
characteristics,  and  equipment  models  to  be 
manipulated  by  the  NETWARS  toolkit. 
This  paper  describes  the  Navy  data 
development  efforts  in  all  of  these 
categories,  and  also  discusses  the  long  term 
goals  in  anticipation  of  supporting  other 
Navy/DOD  M&S  programs. 


map,  of  the  entities  involved  in  the 
simulation,  their  movement, 

communications  devices  and  the  networks 
and  links  utilized.  The  output  of  the  front 
end  is  an  ASCII  Simulation  Description  File 
(SDF)  which  is  submitted  to  the  OPNET 
environment  for  simulation  (Figure  1). 
Each  service  is  responsible  for  providing 
simulation  specific  data,  such  as  the  entities 
involved  in  the  scenario,  their  movement, 
communications  devices  located  on  those 
entities,  networks  and  links  utilized,  traffic 
flowing  in  and  out  on  those  network/links, 
and  finally  models  of  the  communications 
devices. 


O&tabase 
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1.  INTRODUCTION 


Figure  1:  NETWARS  Architecture 


The  goal  of  NETWARS  [6]  is  to  provide  a 
Joint  Task  Force  (JTF)  simulation 
environment  that  allows  the  end  user  to 
determine  bottlenecks  in  the  military 
communications  infrastructure  and  evaluate 
emerging  communications  technologies. 
This  IS  accomplished  through  the 
development  of  a  NETWARS  toolkit, 
comprised  of  a  front-end  graphical  user 
interface,  and  a  back-end  comprised  of  the 
OPNET  simulation  environment.  The 
graphical  front  end  allows  the  user  to  create 
JTF  scenarios.  This  entails  the 
specification,  on  a  world 


This  paper  describes  the  Navy’s  data 
collection  and  development  efforts  in  these 
areas  in  support  of  NETWARS.  This  paper 
first  provides  a  brief  overview  of  the  data 
needed  by  NETWARS.  Next,  we  describe 
the  shortfalls  within  the  current  “de-facto” 
Navy  database  and  the  inability  to  fully 
utilize  it  for  NETWARS.  Next,  we  describe 
the  status  of  the  Navy  in  obtaining 
NETWARS  simulation  data  with  regard  to 
the  planned  scenarios,  as  well  as  provide  a 
short  and  long-term  approach  for 
continually  providing  updated  data.  Next, 
we  discuss  the  long  term  Navy  vision  in 
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order  to  provide  the  capability  of  supporting 
Navy/DOD  M&S  programs  in  need  of 
similar  data.  Lastly,  we  provide  a  brief 
summary  and  conclusions. 


2.  NETWARS  DATA  NEEDS 

The  NETWARS  program  has  requested 
each  service  to  provide  specific  simulation 
data.  The  NETWARS  front  end  is 
responsible  for  manipulating  this  data  into  a 
form  that  is  “compatible”  with  the  OPNET 
simulation  engine.  The  front  end  allows 
the  user  to  specify  the  entities  involved  in 
the  simulation  (e.g.,  LEID  ship)  the 
Operational  Facilities,  or  OPFACS,  co¬ 
located  on  the  entities  (e.g..  Fire  Support 
Coordination  Center  FSCC),  system 
equipment  (i.e.  SE)  used  by  the  OPFACS 
(e.g..  AN-WSC  3),  networks  and  links 
connected  to  the  SE,  and  finally  the 
traffic/messages  (i.e..  Information  Exchange 
Requirements  or  lERs)  sent  out  on  the 
networks.  The  front  end  also  allows  the 
user  to  specify  movement  trajectories  for  the 
entities  as  well  as  velocity  to  be  executed 
during  the  course  of  the  simulation.  Once 
a  scenario  has  been  constructed  in  the  front 
end,  it  is  passed  to  the  OPNET  simulation 
engine  for  evaluation. 

The  Navy  is  working  to  provide  entities, 
OPFACS,  SEs,  networks  and  links,  and 
lERs  for  the  different  NETWARS  scenarios. 
Four  scenarios  are  being  developed  for 
evaluation  in  the  NETWARS  toolkit.  These 
scenarios  include  a  portion  of  the  Unified 
Endeavor  scenario  from  STOW97, 
appropriately  modified  to  emphasize 
communications.  This  scenario  is  called 
South  West  Asia  (SWA)  1000,  and  contains 
1000  OPFACS  and  5000  System  Elements. 
A  follow-up  scenario  to  SWA  1000  is  SWA 
5000,  to  denote  the  increase  to  5000 
OPFACS  and  20,000  SE’s.  The  third 
scenario  is  the  North  East  Asia  (NEA)  5000 
and  the  fourth  scenario  will  be  developed 
for  the  Quadrennial  Defense  Review 
(QDR).  The  current  timeline  for  providing 
data  has  been  extended,  with  August  2000 
as  the  cutoff  for  the  SWAIOOO  scenario,  and 
February  2001  as  the  cutoff  for  the 
SWA/NEA  5000  scenario.  The  timelines 
for  the  other  scenarios  are  still  pending. 


3.  SHORTFALLS  IN  NAVAL 
ARCHITECTURE  DATABASE  (NAD) 


The  Naval  Architecture  Database  (NAD)  [5] 
has  been  developed  by  SPAWAR  05 1  and  is 
the  “de-facto”  standard  that  implements  the 
Naval  C4ISR  Operational,  Systems  and 
Technical  Architectures.  The  NAD  does 
have  some  of  the  structure  to  support  the 
data  necessary  for  NETWARS;  however, 
certain  key  attributes  are  either  missing  or 
are  vague.  A  review  of  the  NAD  revealed 
several  deficiencies.  The  NAD  does  not 
contain  any  System  Equipment  (SE) 
relationships  with  OPFACS.  It  only 
contains  descriptions  of  SHIP-to-OPFAC 
relationships  and  SE  nomenclature.  The 
NAD  does  contain  the  lER’s,  however, 
critical  values  and  fields  are  either  vague  or 
non-existent.  For  example,  the  following 
fields  are  non-existent: 

•  urc  code, 

•  proclucingecheloncode, 

•  consumingecheloncode, 

•  application_name_prod_code, 

•  applicationnameconscode. 

The  lER  attributes  of  frequency  and  size  are 
often  qualitative.  For  instance,  the 
frequency  values  are  defined  as  periodic, 
continuous  and  as-needed.  The  volume  size 
values  are  defined  as  high,  medium  or  low. 
Clearly,  these  are  not  sufficient  for  a 
detailed  NETWARS  simulation.  In 
addition,  the  NAD  does  not  contain  a 
network/link  relationship  to  the  SE’s. 

In  spite  of  the  shortcomings  of  the  NAD, 
certain  information  was  obtainable. 
Specifically,  the  NAD  was  used  to  obtain 
"operational-level"  type  information  such  as 
OPFAC-to-OPFAC  communication  (i.e., 
which  OPFACS  communicate  with  each 
other),  and  also  the  OPFACS  contained  on 
the  Navy  ships.  One  of  the  goals  of  the 
Navy  is  to  formulate  a  plan  of  action  to 
integrate  the  data  needed  by  NETWARS 
into  the  NAD.  However,  the  data  must  be 
validated  before  being  included  in  the  NAD. 
This  validation  process  will  be  handled  by 
SPAWAR  051.  The  entire  process  can  be 
seen  in  Figure  2. 
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Figure  2:  Plan  of  Action  for  Navy 
NETWARS  Support 


4,  NAVY  STATUS 

The  Navy  has  developed  Amphibious 
Readiness  Group  (ARG)  models  that 
conform  to  NETWARS  standards  version  2. 
These  models  have  been  through  an  in- 
house  verification  and  validation  process, 
however  the  formal  V&V  process  will  be 
completed  in  December  2000.  In  the 
interim,  the  NETWARS  Program  Office  has 
agreed  to  use  these  models,  with  an 
understanding  that  they  have  not  been 
through  a  formal  V&V  process.  The  Navy 
will  fully  participate  in  the  SWA5000/NEA 
5000  study  currently  projected  to  start  in  FY 

Since  V&V  models  are  projected  to  be 
available  for  the  SWA/NEA  5000  study,  the 
Navy  NETWARS  team,  with  concurrence 
from  the  Navy  Modeling  and  Simulation 
Management  Office  (N6M),  will  place  all 
lER  development  efforts  to  support  the 
SWA  and  NEA  5000  study.  All  products 
(e.g.  lERs  and  models)  that  will  be  available 
for  the  SWA  1000  will  be  provided  to  the 
NETWARS  program  office  with  an 
understanding  that  the  data  may  not 
accurately  reflect  Navy  networks  and  its 
associated  traffic. 

Since  an  in-depth  analysis  of  the  NAD 
revealed  several  key  deficiencies,  the  Navy 
NETWARS  team  met  to  discuss  a  long-term 
strategy  to  obtain  the  data  needed  by  future 
NETWARS  scenarios. 

5,  lER  SHORT  AND  LONG  TERM 
APPROACH 

The  Navy  has  chosen  to  develop  short  term, 
as  well  as  long  term  plans  for  data 
development.  The  motivation  for  this 
decision  is  so  that  NETWARS,  and  other 
proCTams  like  Joint  Tactical  Radio  System 
(JTRS)  [1],  project  milestones  and  timelines 
are  met,  while  at  the  same  time  the  long 
term  resources  and  tasks  are  on  track  so  that 
detailed  data  can  be  collected  and  formally 
verified  and  validated.  For  example,  a 
short-term  solution  might  be  to  obtain  only 
those  lER  attributes  that  will  at  the  very 
minimum  allow  a  simulation  to  occur. 
These  attributes  would  include  producing 
OPFAC,  consuming  OPFAC,  size  of  the 
lER  generated  by  the  producing  OPFAC  and 
sent  to  the  consuming  OPFAC,  and 
frequency  of  the  lER  sent  by  the  producing 
OPFAC  to  the  consuming  OPFAC.  The 
longer-term  goal  would  be  to  obtain  other 


lER  attributes,  such  as 

producing/consuming  echelon  code,  trigger 
events,  threading  events,  and  task-to-IER 
relationships.  The  types  of  lER’s  to  be 
collected  include  voice,  data  and  VTC. 
Table  1  lists  the  short  and  long  term 
approaches  for  lER  data  collection. 

Table  1:  lER  Short  and  Long  Term  Plan 
of  Action 


Short  Term 

Long  Term 

Data  lER 

•  Personal  Interviews  (Phibgru) 

•  Ship  Logs 

•  NOAC 

•  DERA  (JIFM) 

•  TIRA 

•  Ship  Logs 

Voice  lER 

•  HDD  Parameterization 

•  Personal  Interviews  (Phibgru) 

•  Ship  Logs 

•  UCLA  Work 

•  Ship  Logs 

VTC  lER 

Combination  of  Above 

Combination  of  Above 

The  Network  Operations  Analysis 
Capability  (NOAC)  [2]  supports  network 
analysis  by  providing  actual  network  data  as 
inputs  to  analytical  tools.  The  collection  of 
network  data  will  be  accomplished  via 
network  sniffers  and  managers  such  as  HP 
OpenView  and  HP  Net-Metrix.  A  prototype 
demonstration  will  be  operational  on  the 
USS  Coronado  in  August  2000. 

The  Defense  Engineering  and  Research 
Agency  (DERA)  in  the  IJR  is  also  involved 
in  several  programs  dealiim  with  the 
collection  of  lER  data.  One  specific 
OTOgram  is  called  the  Joint  Information 
Flow  Model  (JIFM).  A  unique  approach 
taken  by  JIFM  includes  collection  of  the 
lER  in  user  terms,  and  not  in  terms  of  bits  or 
bytes.  The  advantage  to  this  approach  is 
that  it  can  be  used  to  define  a  set  of 
doctrinally  based  lER’s,  from  which  future 
lER’s  can  be  developed.  In  addition  to 
JIFM,  DERA  is  also  developing  a 
simulation  environment  called  the 
Information  and  Network  Simulation  and 
Evaluation  Tool-set  (INSET).  The 
relationship  between  JIFM  and  INSET  can 
be  seen  in  Figure  3. 
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Figure  3:  JIFM  and  INSET 


The  Tool  for  Interoperability  Risk 
Assessment  (TIRA)  is  a  SPAWAR  effort, 
leveraging  work  from  the  Distributed 
Engineering  Plant  (DEP)  and  Joint  DEP. 
TIRA  provides  risk  assessment  and  analysis 
with  regards  to  the  interoperability  of  joint 
and  Navy  systems.  The  test  results 
captured  through  TIRA  include  network 
information  (e.g.,  OTCIXS),  information 
type  (e.g.,  voice,  video,  etc),  sending  and 
receiving  applications,  mission  area  and 
network  latency.  One  of  the  long-term 
objectives  is  to  assess  whether  or  not  TIRA 
can  be  used  to  provide  data  to  NETWARS. 

The  Hierarchical  Data  Dictionary  (HDD) 
represents  a  hierarchical  organization  and 
description  of  the  information  (lER’s)  in  the 
NAD.  In  other  words,  each  lER  in  the  NAD 
is  categorized  according  to  the  HDD.  The 
HDD  parameterization  technique  involves 
the  determination  of  the  lER  size  and  lER 
frequency  driving  parameters  for  each  of  the 
HDD  entries  associated  with  the  lER’s. 
This  is  very  similar  to  the  approach  DERA 
is  undertaking  with  JIFM.  Tne  benefits  of 
this  approach  are  that  there  are  far  fewer 
HDD  entries  than  there  are  lERs  in  the 
NAD.  Also,  it  has  the  advantage  that  the 
lERs  are  developed  in  operator  terms. 

6.  COMMUNICATIONS  MODELS 

The  NETWARS  program  provides  an  M&S 
capability  to  the  Commanders-in-Chief 
(CJNCs).  The  NETWARS  toolkit  provides  a 
robust  capability  to  analyze  the  impact  of 
new  technology  on  battle  group 
communications  and  the  performance  of 
large-scale  communication  environments 
such  as  in  a  JTF.  The  NETWARS  analysis 
requirements  highlight  the  need  for  models 
with  varying  levels  of  fidelity  and 
aggregation  [3].  The  ability  to  interface  a 
variety  of  models  with  differing  levels  of 
fidelity  has  several  technical  challenges.  For 
example,  in  order  to  determine  the  impact  of 


new  radios  on  the  communication 
performance  of  a  JTF,  it  may  be  necessary 
to  insert  a  high  fidelity  model  of  a  radio  into 
a  low  fidelity  environment.  In  previous 
NETWARS  demonstrations,  this  procedure 
resulted  in  very  long  run-times  for  the 
simulations.  This  issue  of  multi-resolution 
modeling  has  been  a  concern  in  the  M&S 
community. 

The  Navy  has  recently  developed  an 
innovative  approach  that  resolves  problems 
through  multi-resolution  modeling.  The 
NavyN  approach  utilizes  functional  models 
and  integrated  analytic  techniques  [3]  [4]. 
This  approach  has  been  presented  at 
previous  J6  technical  working  groups  and 
resulted  in  positive  collaboration  with  the 
Air  Force,  Marines  and  Army.  In  addition, 
these  functional  models  will  enhance  the 
Naval  Space  Command  Modeling  initiatives 
in  analyzing  bandwidth  requirements  for  an 
ARG  and  BG  for  the  year  2005.  These 
Navy-specific  models  validated  the  multi- 
resolution  approach  and  modeling  standards 
methodologies. 

The  architecture  of  these  models  was 
produced  to  reduce  simulation  run-time  and 
provide  a  mechanism  to  run  low  fidelity 
with  high  fidelity  models.  The  key  to 
reducing  the  run-time  was  an 
implementation  of  hybrid  models  that 
included  equations  or  curves  of  network 
performance.  With  a  discrete  time 
simulation  engine,  much  processing  is 
required  to  track/process  all  events  created 
by  the  interaction  of  models.  The  Navy  had 
successfully  deployed,  in  previous  work,  a 
method  of  reducing  the  number  of  events, 
which  in  turn  significantly  reduced 
simulation  run-time.  Additional  functions 
are  also  included  in  this  work  to  further 
reduce  run  time,  such  as  centralizing 
network  switching/routing.  This  work  also 
provides  an  alternate  to  OPNET’s 
traditional  pipeline.  Models  of 

communication  links  provide  a  medium  that 
has  attributes  to  account  for  effects  of 
propagation  [2]. 

6.1  Modeling  Approach 

The  NETWARS  program  requires  JTF 
simulation  scenarios  with  up  to  20,000 
nodes.  In  order  to  accommodate  manageable 
run-time  requirements  of  scenarios  with 
large  numbers  of  nodes  and  to  produce 
MOEs  and  MOPs  of  appropriate  accuracy, 
performance  functions  are  used  where 
appropriate  to  compute  the  performance  of 
simulated  device  and  entity  models.  A 
performance  function  is  a  mathematical 
function  that  computes  the  specific 
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performance  value(s)  based  on  the  current 
operating  point  in  the  operating  range  of  a 
device  or  entity.  Examples  of  performance 
results  include  message  delay  and  loss 
across  a  point-to-point  link,  message  latency 
through  a  switch,  and  access  delay  through  a 
media  controller.  Performance  functions  are 
to  be  based  on  analytical  results,  field 
exercises  and  tests,  and  more  detailed  and 
focused  simulation  studies  of  devices.  The 
structures  of  performance  functions  include 
mathematical  equations  and  table  look-ups. 
The  modular  development  of  models  allows 
for  the  enhancements  and  updates  of 
performance  functions  as  required.  Figure  4 
provides  an  illustration  of  the  use  of 
performance  functions  in  the  calculation  of 
performance  results  for  simulated  device 
models. 


Figure  4:  Performance  Function 
Approach 

The  MAC  function  library  was  designed  to 
model  the  effects  of  shared  communications 
media  on  message  transmissions.  These 
effects  include  message  delays  and  losses. 
The  MAC  function  library  utilizes 
performance  functions  to  characterize  these 
effects  by  including  both  the  transmission 
medium  and  the  contention  protocol  in  a 
single  link  model  entity.  The  modularity  and 
flexibility  of  these  functions  facilitate  the 
modeling  of  a  variety  of  serial,  bus  and 
wireless  link  types.  Link  model  performance 
and  operation  are  derived  from  performance 
functions,  as  illustrated  in  Figure  5. 
Message  delays  and  loss  effects  are 
determined  from  performance  functions  that 
are  based  upon  several  link  conditions.  Link 
conditions  may  consist  of  several  factors, 
such  as  the  number  packet  arrivals  per  unit 
time  or  the  number  of  active  traffic  sources, 
or  taps,  on  a  link. 


Node 


Figure  5:  MAC  Layer  performance 
function 

Network  routing  provides  the  capability  for 
message  delivery  among  nodes  across  a 
network.  Network  elements,  such  as  routers 
and  switches,  typically  utilize  routing 
protocols  to  build  and  update  routing  tables 
m  a  distributed  fashion.  A  centralized 
process  that  facilitates  the  modeling  of  these 
routing  protocols  has  been  developed  for  the 
Navy  Battle  Group  model  suite.  This  routing 
process  is  responsible  for  the  development 
and  maintenance  of  the  routing  tiwology  for 
the  entire  network  model.  Centralized 
management  of  the  routing  process  may 
significantly  increase  simulation  efficiency 
with  respect  to  run-time  performance  for 
large-scale  network  simulations.  The  routing 
process  maintains  a  central  routing  topology 
m  a  format  that  is  compatible  with  the 
structure  that  is  defined  within  the  OPNET 
routing  kernel  procedure  package.  This 
allows  the  process  to  implement  routing 
functions  and  interoperate  with  many 
elements  of  the  OPNET  routing  kernel 
procedure  package.  The  routing  process  also 
supports  flexibility  objectives  by  extending 
routing  services  to  most  packet-switched 
protocols  and  link  layer  switching  protocols. 
Initially,  the  routing  process  supports  the 
OPNET  minimum-hop  routing  algorithm. 
The  routing  process  can  be  enhanced  in  the 
future  to  support  static,  user-defined  routes 
and  dynamic  routing  protocols  such  as  the 
Routing  Information  Protocol  (RIP)  and 
Open-Shortest-Path-First  (OSPF). 


6.2  Navy  Carrier  Battle  Group 

The  modeling  approach  described  above 
was  implemented  in  the  development  of 
Navy  NETWARS  models.  At  the  Network 
editor  layer  of  OPNET,  models  of  each  class 
of  ships  in  a  traditional  battle  group  were 
developed  by  populating  an  appropriate  set 
of  C41SR  systems  that  are  provided  by  the 
Navy  system  OPNET  palette.  At  the 
link/physical  layer,  each  ship  is  provided  RE 
resources  based  on  Operational  Navy 
communication  plans.  Additional  details  on 
the  construction  of  an  Amphibious 
Readiness  Group  and  Carrier  Battle  Group 
are  available  in  references  [7]  and  [8]. 
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Figure  6  is  an  example  of  a  Carrier  Battle 
Group 


Figure  6:  Network  Editor  View  of  a  Navy 
Carrier  Battle  Group 

The  approach  above  provided  significant 
reduction  in  run-times,  that  in  turn  provided 
Navy  analysts  the  capability  to  perform 
multiple  “what-if’  type  experiments. 
Recently,  JMSAC  analysts  studied  the 
performance  of  a  fairly  complex  system, 
which  in  past  simulation  studies  were 
difficult  to  perform  due  to  lengthy  run 
times. 


6.3  Automated  Digital  Network  System 

Automated  Digital  Network  System 
(ADNS)  incorporates  the  latest  advances  in 
commercial  and  military  communications 
technology  to  maximize  bandwidth, 
enabling  seamless  information  sharing 
through  flexible,  adaptive  and  interoperable 
systems  and  services.  ADNS  provides  both 
tactical  improvements  to  the  warfighter  and 
non-tactical  quality  of  life  services  to  sailors 
at  sea  and  ashore,  ft  is  based  on  industry 
accepted  standards  for  management,  routing 
and  switching,  using  commercial  off  the 
shelf  (COTS)  products.  ADNS  interfaces 
user  information  systems  available  to  the 
platform  and  will  be  present  on  all  Navy 
platforms.  The  various  Information 
Exchange  Subsystems  (IXS)  currently  in 
place  today  utilize  proprietary  protocols  to 
serve  very  specialized  interests.  These  IXS 
will  hinder  the  miration  to  an  open 
architectural  approach.  In  order  to  shift 
away  from  stovepipe  IXS  protocols, 
information  system  applications  need  to  be 
restructured  to  support  an  IP  based  network. 
A  significant  number  of  issues  need  to  be 
addressed  such  as  precedence,  priority,  and 
timeliness.  ADNS  provides  baseband 
connectivity  and  networking  services  (voice, 
video,  and  data)  to/from  end  user  systems 


(Navy,  Allied  and  Joint).  ADNS  uses 
standard  compliant,  commercial  networking 
products  and  control  technology  to  achieve 
Joint  and  Allied  interoperability. 

ADNS  initially  debuted  in  Joint  Warfighter 
Interoperability  Demonstration  95  (JWID 
95)  where  it  was  extremely  successful  in 
providing  specific  capabilities,  such  as  IP 
routing  and  dynamic  bandwidth 
management.  ADNS  demonstrated  a  marked 
improvement  in  resource  utilization  by 
routing  data  from  multiple  sources  over 
otherwise  idle  communications  paths.  This 
capability  provides  efficient  access  to  single 
or  multiple  satellite  channels.  These  and 
other 

early  results  validated  the  ADNS  approach 
and  set  the  stage  for  future  developments  to 
achieve  the  Copernicus  vision. 

A  simulation  (Figure  7)  was  performed  in  a 
network  of  5  ships  connected  via  SATCOM 
(e.g.  EHF,  SHF,  UHIA  and  Point-to-Point 
links  (e.g.  HF  and  UHF  LOS).  Performance 
runs  on  latency  of  HTTP  downloads  via 
SATCOM  with  Bit-Error-Rate  10'®  through 
1 0'^  were  obtained  in  a  pre-defmed  scenario 
[8]  with  run-times  of  less  than  3  minutes 


FTP  Client  Download  Response  Time  Link  Rate  16  Kbps. 


Figure  7:  HTTP  Latency  results 


7,  LONG  TERM  NAVY  VISION 

The  long-term  vision  within  the  Navy 
NETWARS  working  group  is  to  eventually 
incorporate  all  of  the  aforementioned  data 
into  the  NAD  (or  at  least  an  interim 
database  until  V&V  can  be  done).  Over  the 
course  of  the  year,  discussion  within  the 
Navy  NETWARS  working  group  has 
brought  forth  a  vision  to  integrate  many  of 
the  Navy  databases  into  one  "logical" 
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database  that  is  both  CADM  corrmliant,  as 
well  as  compliant  with  the  DOD  Data 
Architecture  (Figure  8).  Discussions  are  on 
going  with  N6M,  SPAWAR  051,  NRL  and 
Silver  Bullet  Solutions  Incorporated  (SBSI). 


NAD 

Ships,  OPFAC,  lER, 
SE,  network  &  links 

SMIDB 

Equipment  allocation 
aeross  BG  and  ships,  out 
year  budget  planning, 
(discontinued) 

CAP 

Allocating  budget  across 
BGs,  ships,  systems  and 
WBS. 


VIPER 

BG  Scheduling  system 
(c.g.,  movement,  speed)/ 
Used  to  produce  fuel  budget 


across  all  Command  and  Control  sub-functional  areas 


Figure  8:  Long  Term  Navy  Vision 


[4] ,  Legaspi,  Albert.,  Staley,  Thomas., 
Dave’,  Nikhil.,  Ivancic,  Carl.,  Alspaugh, 
Chris.,  Amphibious  Readiness  Group  Multi- 
Resolution  Technolosv  Modelins  Report, 

30  March  2000 

[5]  Naval  Architecture  Database  (NAD): 
http://www.silverbulletinc.com. 

[6]  NET  WARS  Program  Web  site: 
http://www.disa.mil/D8/netwars/index.html. 

[7] .  Navy  NET  WARS  Carrier  Battle 

Group  OPNET  Models,  Joint  Maritime 
Systems  Analysis  Center  (JMSAC), 
SPAWARSYSCEN  D822,  June  2000. 

[8] .  Navy  NETWARS  Amphibious 
Readiness  Group  OPNET  Models,  Joint 
Maritime  Systems  Analysis  Center 
(JMSAC),  SPAWARSYSCEN  D822, 
March  2000. 


8.  SUMMARY  AND  CONCLUSIONS 

The  Navy’s  extensive  experience  in  network 
modeling  and  simulation  has  resulted  in  an 
innovative  approach  to  handling  the  multi¬ 
resolution  objectives  of  NETWARS.  This 
technology  was  used  in  the  development  of 
C41SR  communication  systems  for  an  ARG. 
In  addition,  models  of  a  Battle  Group  are 
being  built  for  future  NETWARS  studies. 

In  anticipation  of  studies  that  are  to  be 
included  in  the  QDR,  the  Navy  is  currently 
taking  models  through  a  formal  V&V 
process.  This  will  ensure  that  each  system 
(including  protocols),  lER  and  transmission 
medium  are  accurately  reflected.  The 
Navy’s  strategic  plan  for  detailed  lER’s  will 

Sort  many  analysis  requirements 

iding  NETWARS. 
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